For a valid claim to priority, the priority application must convey to a person of ordinary skill 
that the inventor(s) had invented or had possession of the claimed invention as of the 
claimed priority date. Hence, the priority application must be examined to ascertain if it 
supports, within the meaning of section 112, H 1, what Is described In the subsequent 
United States application {In re Gosteli, 872 F.2d 1008 (Fed. Cir. 1989)). The test Is 
whether the disclosure of the priority application as filed reasonably conveys to the artisan 
that the inventor had possession at that time of the later submitted subject matter, and not 
just whether there is the presence or absence of literal support in the specification {In re 
Kaslow, 707 F.2d 1366, 217 USPQ 1089 (Fed. CIr. 1983)). The specification must be 
enabling as of the claimed priority date, and must teach those of ordinary skill how to make 
and use the full scope of the claimed Invention without undue experimentation {Hybritech y. 
Monoclonal Antibodies, 802 F.2d 1367 (Fed. Cir. 1986)). 

Furthermore, in Ariad Phanvaceuticals Inc. y. Eli Lilly and Co., the U.S. Court of 
Appeals for the Federal Circuit issued an en banc decision upholding an earlier ruling 
that patent applications must contain a specific "written description" of the claimed 
invention In addition to enabling language explaining how to make and use the 
invention. 

A deciding issue in the October 29, 2010 BPAI decision was: 

For their part, the Appellants do not address the Examiner's reliance on paragraphs 15 and 
26 of the reference. Instead, they merely allege that "no learning of VLAN membership of 
an endstation to its connecting switch is disclosed or suggested by Goodwin. " (App. Br 6.) 

Their allegation does not persuade us of error in the Examiner's findings. Therefore, we 
conclude that the Examiner did not en- in finding that the combined teachings of Jain, 
Walker, and Goodwin would have suggested "learning a correspondence between said CE 
interface and each VLAN identifier included in said at least one tagged frame" as recited in 
claim 20. Page 6, first issue. 
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In particular the BPAI cites the Examiner in this regard: 



One of ordinary skill in the art [would have understood that] [sjource learning learns the 
VLAN information from all unknown packets, not just packets originating from WAN side of 
the switch, rather would learn the correspondences from the LAN side as well (i.e. switch 1 
102 would learn the VLAN conespondences from endstations 108-112 using the "source 
learning" function of the switch. This clearly demonstrates that Goodwin learns the 
correspondences between CE devices and VLAN s .... Sentence bridging page 5 and 6. 

Applicant has argued in the Appeal Brief that: 

But, according to Goodwin, the distant switch connecting the distant endstation knows that 
this distant endstation belongs to VLAN 10, as it is contained in its database from the 
beginning (paragraph [0044] or paragraph [0049]). This provisioning may be 
entered manually, for instance. 

Thus, the learning by Goodwin only relates to VLAN membership propagated over the 
backbone. But a switch always knows the VLAN membership of the endstations connected 
to it. In other words, no learning of VLAN membership of an endstation to its connecting 
switch is disclosed or suggested by Goodwin. Page 6, fourth and fifth paragraph. 

With reference to learning of VLAN membership of an endstation to its connecting switch, 
the present application states in the paragraph bridging pages 9 and 10, which is 
paragraph [0055] in the published specification: 

[0055] When the frame is received at a local CE port (yes in tests 30 and 31), the 
corresponding VPN-id is retrieved in step 32 based on the configuration of the port number, 
and the VLAN identifier is read in the tag header of the frame in step 33. If table T contains 
no other local port number and no VC label for fonA/arding the frame (no in tests 34 and 
35), then the frame is propagated to all the other PE devices in step 36 by pushing the 
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labels of the flooding LSPs previously established. In this step 36, the frame is also 
propagated to any other local CE port of the PE device which has been configured for the 
VPN-id retrieved in step 32. The PE device also allocates a VC label to the (VPN-id, VID) 
pair in view of the reception of frames through the carrier network, and stores it in table T 
(step 37). In step 38, the allocated VC label is sent, along with VPN-id and VID, to all the 
other PES configured for the VPN. This can be done by means of a LDP message (see the 
Internet Draft "draft-martini-l2circuit-trans-mpis-07.txt"). An entry is created in table Tin 
step 39 to learn the relationship between the CE port number and the (VPN-id, VID) pair 
The PE device can then wait for the next Ethernet frame (return to test 30). 

Applicants refer particularly to: 

In this step 36, the frame is also propagated to any other local CE port of the PE device 
which has been configured for the VPN-id retrieved in step 32. 

It is this step which learns the VLAN membership of an endstation to its connecting switch. 
This is to be distinguished from learning the information from other switches, e.g. via the 
backbone. 

It is the Applicant's considered opinion that Goodwin only discloses learning VLAN 
membership propagated over the backbone. Both the Examiner and the BPAI argue that 
the patent application of Goodwin discloses more than this and in fact discloses that also 
the VLAN membership of an endstation to its connecting switch is learned. 

The provisional application from which Goodwin claim priority (60/256,829) makes certain 
statements that have some similarity to the later filed US regular application. For example: 

Membership in VLANs is detemiined by applying policy to specific traffic, and the 

policies are configured VLAN membership is detected by a function within the switch 
called Source Learning. Source Learning applies the VLAN policies during processing of all 
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unknown unicast, broadcast, and multicast frames. Page 1, second paragraph, of 
60/256,829. 

This wording is similar to paragraph [001 5] of the later regular filing. Applicants understand 
this to mean that membership of the VLANs is made by applying policies to traffic, these 
policies being configured or adapted to this job. The statement that VLAN membership is 
detected by a function within ttie switcti called Source Learning refers to the way that 
databases are examined to find out the VLAN membership: 

Currently AutoTracker and VAP maintain separate databases containing MAC 
addresses of devices and their VLAN membership attributes. AutoTracker and VAP 
databases are updated real-time, so that fonvarding of all traffic is based on the most 
recent information. The user has the option to disable the exchange of VLAN information 
(using VAP), and still have the auto-discovery capability active. 

As noted, VAP exchanges MAC-based VIAN membership infonvation between 
switches; therefore, all groups and AutoTracker VLAN configurations should be consistent 
across switches. The AutoTracker VLAN and Group information exchanged can reflect 
information not active in any particular switch. For instance VLANs or Groups can be 
configured but are not necessarily active because there are no endstations active in that 
VLAN. Page 1 , paragraphs 3 and 4 of 60/256,829. 

Each OmniSwitch and PizzaSwitch maintains an AutoTracker related database, which is 
built up by the configured AutoTracker policies and observed traffic. The VAP protocol 
reads the AutoTracker database within the OmniSwitch and advertises these entries to 
other OmniSwitches and PizzaSwitches. VAP generates advertisement frames on regular 
intervals and transmits the protocol over the switched network with all new entries that the 
switch has learned. Page 2, last paragraph of 60/256,829. 

The learning process is carried out by "Autotracker" as explained in the first and second full 
paragraphs on page 2 of 60/256,829: 



5 



AutoTracker will flood the first frame of an unknown source MAC. Flooding allows 
devices to find connectivity to ottier devices, and VLAN membership to be learned by 
switches. Without VAP, loss of connectivity could occur. This is possible when one or more 
devices in the network times out, the VLAN flooding domain is reduced to not include once 
included switches. In a network without VAP, there is no way to recover it unless a device 
starts communicating again. VAP allows all switches to learn that other switches have 
devices in common VLANs, so proper flooding and connectivity can occur 

AutoTracker internally stores VLAN membership using a 32-bit mask. Therefore any 
exchange of information will include the MAC address, the 32-bit mask, and the Group 
identifier 

Applicants understand from the first sentence of the first paragraph that Autotracker floods 
the first frame of an unknown source MAC in such a way that the other switches will 
receive the frame and from this the information from other switches can be obtained via the 
use of VAP. 

How this is done is described in detail on page 15: 

To understand the impact of each of these options, we must first discuss the port 
policies within AutoTracker There are two types of port policies that the OmniSwitch and 
PizzaSwitch support. Both types are mutually exclusive, which means that if one is 
enabled, the other is disabled, therefore both cannot be enabled at the same time. The 
user can configure port policies (with a single user interface command), and depending on 
which type is enabled, the operation of the VLANs will be very different. The user must be 
aware of this distinction. 

One of the types is called the "regular port rules, " where any frames received from the 
specified port will become members of the VLAN. The second is called "port fonA/arding 
rules, " where the port policy is not used upon frame receipt to determine VLAN 
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membership, but instead is used on frame transmission for fonvarding of broadcast, 
multicast, and unf<nown unicast traffic. Ttie default of the switch is port fonfi/arding policies. 
This can be ovemdden by entering the command "reg_j)ort_rule=1 " in the mpm.cmd file. 

The first paragraph explains that Autotracker operates by port policies. This is consistent 
with the second paragraph of 60/256,829 which states as mentioned above: 

Membership in VLANs is detenvined by applying policy to specific traffic 

Also two types of policy are described. In "regular" Autotracker assigns the frames to a 
VLAN. We submit that this not the same as is recited in claim 20 for example : 
- receiving at least one tagged frame from a CE device at each CE interface allocated to 
said VPN, and learning a conrespondence between said CE interface and each VLAN 
identifier included in said at least one tagged frame. 

Assigning frames to a VLAN is not the same as learning a correspondence. 

The second policy is called "port forwarding rules," where the port policy is not used upon 
frame receipt to determine VLAN membership, but instead is used on frame transmission 
for fonwarding of broadcast, multicast, and unknown unicast traffic. 

Accordingly, this second rule (there are only two rules) fonwards the frame without any 
teaming activity being performed. This is consistent with the first full paragraph on page 2 
where it states: 

AutoTracker will flood the first frame of an unknown source MAC. 

In other words, Autotracker fonwards the frame by flooding to other switches and by this 
procedure eventually VAP will propagate the learned information back. 
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However such a forwarding and flooding to other switches does not learn a relationship 
between the endstation and the switch to which it is connected, but instead it allows 
propagation across the backbone of such information. In accordance with the present 

application: 

[0055] When the frame is received at a local CE port (yes in tests 30 and 31), the 
corresponding VPN-id is retrieved in step 32 based on the configuration of the port number, 
and the VLAN identifier is read in the tag header of the frame in step 33. If table T contains 
no other local port number and no VC label for fonfl/arding the frame (no in tests 34 and 
35), then the frame is propagated to all the other PE devices in step 36 by pushing the 
labels of the flooding LSPs previously established. 

This procedure is similar to the fonwarding and flooding operation defined in the second 
rule of Autotracker. 

In addition the present application in the paragraph bridging pages 9 and 10 states: 

In this step 36, the frame is also propagated to any other local CE port of the PE device 
which has been configured for the VPN-id retrieved in step 32. 

This step is not included in the second rule of Autotracker and yet it is this step that allows 
the local learning of the VLAN relationship between the endstation and the switch to which 
it is connected. 

Accordingly, the priority document 60/256,829 of Goodwin is restricted by the above 
paragraphs such that it does not disclose or enable in any reasonable form the step of 
claim 20: 

- receiving at least one tagged frame from a CE device at each CE interface allocated to 
said VPN, and learning a correspondence between said CE interface and each VLAN 
identifier included in said at least one tagged frame. 
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It is remarkable that there is no equivalent of the paragraphs mentioned above from page 
15 of 60/256,829 in the non-provisional patent application of Goodwin. 

Thus Goodwin took the priority provisional application 60/256,829, amplified Its contents, 
added significant text and drawings and removed the restrictive paragraphs on page 15 to 
thereby present a broader invention than was disclosed in its priority provisional 
application. 

Due to this broadening of subject matter, the BPAI therefore concluded of Goodwin: 

This clearly demonstrates that Goodwin learns the conespondences between CE devices 
and VLAN s .... 

Such a conclusion would not have been possible if the BPAI had considered the disclosure 
of 60/256,829. 

Goodwin simply does not disclose the claimed feature: learning ofVLAN membership of an 
endstation to its connecting switch. 

In particular, Goodwin does not provide an enabling disclosure of this feature. Evidence for 
this can be found in the priority provisional application 60/256,829. 

As recited in paragraph 0015 of Goodwin: 

[0015] Membership in VLANs in the exemplary embodiment may be determined by 
applying policy to a specific traffic, and the policies may be configured. VLAN membership 
may be detected by a function within the switch called source learning (e.g., L2 source 
learning). The source learning function may apply the VLAN policies during processing of 
all unknown unicast, broadcast, and multicast frames. 
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Further: 



[0026] Each switch in an exemplary embodiment may maintain a source learning related 
database, which is built up by the configured source learning policies and observed traffic. 

To provide an adequate enabling disclosure Goodwin must explain in reasonable detail 
what such a configured policy is that is applied to specific traffic and especially to unknown 
unicast, broadcast and multicast frames that would be capable of obtaining the claimed 
feature of claim 20 of the present application, namely: 

- receiving at least one tagged frame from a CE device at each CE interface allocated to 
said VPN, and learning a correspondence between said CE interface and each VLAN 
identifier included in said at least one tagged frame. 

In other words it is necessary for Goodwin to explain how this policy is configured in 
sufficient detail for it to be an enabling disclosure. 

Examples of what the skilled person would expect of such a policy are found on page 15 of 
the Goodwin priority provisional application: 

To understand the impact of each of these options, we must first discuss the port 
policies within AutoTraci<er. There are two types of port policies that the OmniSwitch and 
PizzaSwitch support. Both types are mutually exclusive, which means that if one is 
enabled, the other is disabled, therefore both cannot be enabled at the same time. The 
user can configure port policies (with a single user interface command), and depending on 
which type is enabled, the operation of the VLANs will be very different. The user must be 
aware of this distinction. 

One of the types is called the "regular port rules," where any frames received from the 
specified port will become members of the VLAN. The second is called "port fon/i/arding 
rules, " where the port policy is not used upon frame receipt to determine VLAN 
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membership, but instead is used on frame transmission for fonfi/arding of broadcast, 
multicast, and unknown unicast traffic. Tine default of the switch is port fonvarding policies. 
This can be overridden by entering the command "reg_port_rule=1 " in the mpm.cmd file. 

In distinction, the present application does recite in adequate detail such a policy in the 
above-quoted paragraph bridging pages 9 and 10, which for convenience has one 
sentence repeated: 

In this step 36, the frame is also propagated to any other local CE port of the PE device 
which has been configured for the VPN-id retrieved in step 32. 

Goodwin states: 

[0020] The source learning function may flood the first frame of an unknown source MAC. 
Flooding allows devices to find connectivity to other devices, and VLAN membership to be 
learned by switches. 

From the analysis above that this means that any such frame is forwarded to other 
switches and that this phrase does not disclose the propagation of the frame to any other 
local CE port of the PE device, i.e. it does not disclose the relevant feature of claim 20. 

One also learns from Goodwin that: 

[0028] While the source learning function is inspecting traffic regularly VAP is exchanging 
information. 

Thus one knows that the exchange of information, e.g. about VLAN membership is the job 
of VAP and not the source learning function which is inspecting traffic. 

One also learns: 
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[0044] When an endstation sends a frame to the coupled switch, a policy match is 
performed and the endstation is placed in a VLAN. Thus, those ports may be mapped to 
the VLAN dynamically based on traffic patterns. However, the VU\Ns and VLAN 
membership are statically provisioned through the backbone ports of the network 184. 
Across these backbone ports, the switches 182 and 186 advertise the maps on the edges 
to each other. 



As indicated above, assigning an endstation to a VLAN is not the same as learning a 
correspondence. The VLAN membership is statically not dynamically provisioned through 
the backbone. 

In fact nowhere in Goodv\/in is there found an enabled written description of the 
configuration of a policy which by observing trafTic obtains the feature: 

- receiving at least one tagged frame from a CE device at each CE interface allocated to 
said VPN, and learning a correspondence between said CE interface and each VLAN. 

In conclusion Goodwin makes no valid claim to priority and its relevant date is the filing 
date of the non-provisional application, which is December 1 9, 2001 , and which post dates 
the foreign priority filing date of the present application which is December 7, 2001 . The 
earlier foreign priority date of the present application means that the subject matter of 
Goodwin was not described in a printed publication before the invention thereof by the 
applicant for patent, nor was it described in a printed publication more than one year prior 
to the date of the application for patent in the United States (35 USC 102(a) and (b)). 
Hence Goodwin is not prior art with respect to the present application. 

Finally it is necessary to show that: 

Section 1 1 9 provides that a foreign application 'shall have the same effect' as if it had been 
filed in the United States. 35 U.S.C. § 1 19. Accordingly, ... the foreign priority application 
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must be examined to ascertain if it supports, within the meaning of section 1 12, ^ 1 , what is 
claimed in the United States application." In re Gosteli, 872 F.2d 1008 (Fed. Cir. 1989) 

Priority filing EP 01403179.3 of the present application is substantially identical to the 
present application. In particular in the paragraph bridging pages 9 and 10 the exact 
method by which a local switch leams the VLAN information of an endstation connected to 
that switch is described in an identical manner to that in the present application. 

Thus the claim to priority of the present application is fully supported. 

It is therefore submitted that the priority of the present application to EP 01403179.3, filed 
December 7, 2001 is supported and Goodwin US 2002/01 241 07 is entitled to only its filing 
date of December 19, 2001. The present application therefore predates Goodwin, and 
Goodwin is not a proper reference. 

Further and favorable reconsideration of the present application is therefore urged. 
December 27, 2010 Respectfully submitted 
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